還記得昨天我們提到企業願意付費的功能有哪些類型嗎？其中有一項是 High Availability 高可用。

今天我們就來介紹，GitLab 提供高可用架構的付費功能—GitLab Geo。

首先，GitLab Geo 是只適用於自架 GitLab 的情境，畢竟 GitLab.com 這個 SaaS 服務，原廠當然是自己處理了高可用的問題。

GitLab Geo 能用來解決幾種企業常見的情境：

1. 備援機制：GitLab Geo 可以替自架的 GitLab 建立「熱備援」的架構。
2. 分散流量：如果你有大量的使用者，想要適度的分流，也可以使用 Geo 來處理。因此 Geo 就如其名，你可以為分散在兩地工作的團隊架設 GitLab Geo 架構，讓兩地的團隊各自連上離自己距離較近的 GitLab，減少地理距離造成的網路速度問題。
3. 讀寫分離：延續上一個情境，Geo 其實也是一種「讀寫分離」的架構，只有主要的 Primary site 處理資料寫入的動作，而其他的 Secondary site 只提供資料讀取，如果在 Secondary site 上執行 git push，會被自動導流到 Primary site。

在上面的描述中，我提到了 Primary site 與 Secondary site，相信聰明的讀者看到這裡，應該不難理解，基本上使用 Geo 即意味著，你其實是在搭建多台 Self-managed GitLab，然後透過 Geo 將它變成原廠所謂的 Primary site 與 Secondary site 的架構。

因此，我們要有一個正確的認知，Geo 不只是讓我們針對 GitLab 提供的 Git 功能做備援，它正確定位是「為整個 GitLab instance 建立備援」，因此不論 Primary site 與 Secondary site，它們本質上各自都是一座完整的 GitLab，有著自己的 Domain name，只是透過 Geo 被串連在一起，套上了 Proxy 機制，形成了一種主從的狀態。

最後，要提醒一下 Geo 也不是萬能的，雖然熱備援架構讓它可以盡可能即時的同步 Primary site 與 Secondary site 上的資料，但如果你遇到 Primary site 損毀修復不能的狀況時，Geo 尚不支援自動將 Secondary site 提升成為 Primary site；想要用 Secondary site 取代已損毀的 Primary site，目前只能手動處理。

另外就跟其他產品供應商一樣，GitLab 在文件中也清楚地說明了 Geo 能提供的高可用範圍。Geo 只負責提供 GitLab 本身的高可用，像是 AD / LDAP 這些其他相依系統的高可用，當然是使用者要自己處理的。（白話文就是，如果你的 AD 因為欠缺高可用而服務停擺，甚至影響到 GitLab，那個不在 GitLab 的處理範圍喔～）

Geo 的介紹就到此為止，你的企業有自架 GitLab 嗎？當你的使用量、使用人數、資料量越來越多時，不妨考慮一下 Geo 這個付費功能喔！

圖片來源 - 吉卜力工作室 https://www.ghibli.jp/works/kazetachinu/#&gid=1&pid=25